home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 5518 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.0 KB
  1. Path: buggus.mmg.uci.edu!user
  2. From: mangalam@uci.edu (Harry Mangalam)
  3. Newsgroups: comp.lang.c
  4. Subject: Different stdout End-of-output with redir '>' and stdout to screen
  5. Date: Fri, 09 Feb 1996 17:59:18 -0800
  6. Organization: Microbiology and  Molecular Genetics, UC Irvine
  7. Message-ID: <mangalam-0902961759180001@buggus.mmg.uci.edu>
  8. NNTP-Posting-Host: buggus.mmg.uci.edu
  9.  
  10. HI All,
  11.    This may not be a pure C question and for that I apologize.  I'm
  12. writing a pure ansi C program (no comiler complaints under SGI's cc or gcc
  13. under Linux) that reads in a bunch of DNA sequence (acgt's), performs some
  14. manipulations and spits the output to stdout.  It works surprisingly well
  15. (thanks, Steve Summit et al for the FAQ!! (which I've examined with no
  16. luck, although it could be boneheadedness on my part)), but I've run
  17. across an interesting/confusing bug/ignorance-on-my-part.
  18.  
  19. When the output is allowed to dump to the screen, it does exactly what I
  20. expect it to do, but when the output is redirected to a file via ">", I
  21. get a duplication of the last part of the output.  ie:
  22.  
  23. to screen (correct output):
  24.       .  
  25.       .
  26.       .
  27.                                                  TfiI
  28.                                                  HinfI
  29.                             MboI               NlaIII
  30.                             DpnII   AlwI   AflIII
  31.            BsrI               DpnI  Tth111II   NspI
  32.            \                \ \     \      \   \ \
  33.   31921   gttccagtagcaagcataggatcaagaataataacatgtgaatcagagatgttttcaggc  31980
  34.           caaggtcatcgttcgtatcctagttcttattattgtacacttagtctctacaaaagtccg
  35.               ^    *    ^    *    ^    *    ^    *    ^    *    ^    *
  36.           V  P  V  A  S  I  G  S  R  I  I  T  C  E  S  E  M  F  S  G
  37.  
  38.                  SfaNI
  39.                  \
  40.   31981   atctttttatagtatgaaa                                           32040
  41.           tagaaaaatatcatacttt
  42.               ^    *    ^    *    ^    *    ^    *    ^    *    ^    *
  43.           I  F  L  Z  Y  E
  44.  
  45.  
  46.  
  47. to file via ">" (incorrect output):
  48.       .  
  49.       .
  50.       .
  51.                                                  TfiI
  52.                                                  HinfI
  53.                             MboI               NlaIII
  54.                             DpnII   AlwI   AflIII
  55.            BsrI               DpnI  Tth111II   NspI
  56.            \                \ \     \      \   \ \
  57.   31921   gttccagtagcaagcataggatcaagaataataacatgtgaatcagagatgttttcaggc  31980
  58.           caaggtcatcgttcgtatcctagttcttattattgtacacttagtctctacaaaagtccg
  59.               ^    *    ^    *    ^    *    ^    *    ^    *    ^    *
  60.           V  P  V  A  S  I  G  S  R  I  I  T  C  E  S  E  M  F  S  G
  61.  
  62.                  SfaNI
  63.                  \
  64.   31981   atctttttatagtatgaaa                                           32040
  65.           tagaaaaatatcatacttt
  66.               ^    *    ^    *    ^    *    ^    *    ^    *    ^    *
  67.           I  F  L  Z  Y  E
  68.  
  69. ^    *
  70.           I  F  L  Z  Y  E
  71.  
  72. Note last 2 lines - this can be of variable length, repeating up to 30 or
  73. more lines of the last part of the output.
  74.  
  75. This sounds like it might be the failure to correctly terminate a string,
  76. leading to a 'run-on' past the supposed end of the string, but the program
  77. clears that chunk of memory via a memset call (verified to work correctly
  78. with a debugger), so that even if it ran on, it shouldn't be intelligible
  79. characters.  It 'feels like' the system is clearing a buffer to stdout at
  80. program termination.
  81.  
  82. I've tried:
  83.       fflush (stdout);
  84. and 
  85.       fclose (stdout); 
  86. with no difference in output.
  87.  
  88. Is there a system call to terminate anything more going out to stdout? 
  89. And if something like that was involved, why would the output to screen
  90. work correctly all the time?
  91.    This has been tried and works identically on IRIX 5.3 and Linux 1.2.8.
  92.  
  93.  
  94. Any direct insight or rtfm pointers would be appreciated.
  95. Thanks and Cheers
  96. harry
  97. -- 
  98. Harry J Mangalam, Microbiology and Molecular Genetics, UC Irvine,
  99.       Irvine, CA, 92717, (714) 824-4824, fax (714) 824 8598
  100.             http://hornet.mmg.uci.edu/~hjm/hjm.html
  101.   Computational Biology..SGI..Woodworking..Bicycling..Linux..WWW 
  102.